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ABSTRACT 

The Microwave Anisotropy Probe mission is designed 
to produce a map of the cosmic microwave background 
radiation over the entire celestial sphere by executing a 
fast spin and a slow precession of its spin axis about the 
Sun line to obtain a highly interconnected set of 
measurements. The spacecraft attitude is sensed and 
controlled using an inertial reference unit, two star 
trackers, a digital sun sensor, twelve coarse sun sensors, 
three reaction wheel assemblies, and a propulsion 
system. This paper presents an overview of the design 
of the attitude control system to carry out this mission 
and presents some early flight experience. 

INTRODUCTION 

The Microwave Anisotropy Probe (MAP), the second 
Medium-Class Explorer (MIDEX) mission, was 
launched on June 30, 2001 as a follow-on to the Cosmic 
Background Explorer (COBE), which made precise 
measurements of the Cosmic Microwave Background 
(CMB) that is believed to be a remnant of the Big Bang 
marking the birth of the universe. 1-4 Figure 1 is an 
equal-area plot in galactic co-ordinates of the 
anisotropy in the temperature of the CMB as measured 
by the Differential Microwave Radiometer (DMR) 
instrument on COBE. The red band along the equator is 
due to local microwave radiation from our galaxy; it is 
not related to the CMB. MAP has been designed to 
measure the CMB anisotropy with sensitivity 50 times 
that of DMR and angular resolution 30 times finer, 
specifically 20 microKelvin and 14 arc minutes, 
respectively, as simulated in Figure 2. These increases 
in sensitivity and resolution will enable scientists to 
determine the values of key cosmological parameters 
and to answer questions about the origin of structure in 
the early universe and the fate of the universe. 6 

Since the major error sources in the DMR data arose 
from COBE’s low Earth orbit, MAP was placed in a 
Lissajous orbit around the Sun-Earth Lj Lagrange point 
to minimize magnetic, thermal, and radiation 
disturbances from the Earth and Sun. MAP attained its 
Lissajous orbit around L 2 in early October 2001, about 
100 days after launch, using a lunar gravity assist 
following three phasing loops, as shown in Figure 3. 7 



Figure 2: Simulated MAP CMB Map 



- \ j 


Figure 3: MAP Trajectory to L 2 
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The MAP instrument includes radiometers at five 
frequencies, passively cooled to about 90°K, covering 
two fields of view (FOVs) 141° apart on the celestial 
sphere. The MAP observatory executes a fast spin at 
0.464 rpm and a slower precession of its spin axis at 
one revolution per hour at a constant angle of 22.5 
from the Sun line to obtain a highly interconnected set 
of measurements over an annulus between 87° and 132° 
from the Sun. Figure 4 shows the scan pattern covered 
by one of the two FOVs in one complete spacecraft 
precession (1 hour), displayed in ecliptic coordinates in 
which the ecliptic equator runs horizontally across the 
map. The bold circle shows the path for a single spin 
(2.2 minutes). As the Earth revolves around the Sun, 
this annulus of coverage revolves about the ecliptic 
pole. Thus the entire celestial sphere will be observed 
once every six months, as shown in Figure 5, or four 
times in the planned mission life of two years. 

This paper give an overview of the Attitude Control 
System (ACS) that acquires and maintains the 
spacecraft orbit, controls the spacecraft angular 
momentum, provides for safety in the event of an 
anomaly, and implements the spin-scan observing 
strategy while minimizing thermal and magnetic 
fluctuations, especially those synchronous with the spin 
period. More detail can be found in Refs. 8 and 9. 


North Elliptic. Pota 



Figure 4: MAP Scan Pattern 


6 Months 



Figure 5: MAP Spin-Scan Concept 


Day 1 
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ACS OVERVIEW 

MAP uses three right-handed, orthonormal co-ordinate 
systems. The Geocentric Inertial frame (GCI) is an 
Earth-centered frame with its Xi axis pointing to the 
vernal equinox, its z, axis pointing to the North 
Celestial Pole (parallel to the Earth's spin axis), and 
y, = zi x X], The Rotating Sun Referenced frame (RSR) 
is a spacecraft-centered frame in which the z R axis 
points from the MAP spacecraft to the Sun, x R is a unit 
vector in the direction of z R x z h and y R = z R x x R . The 
RSR frame rotates at approximately l°/day with respect 
to the GCI frame. The body frame is centered at the 
spacecraft center of mass with z B axis parallel to the 
spacecraft centerline, directed from the instrument to 
the solar arrays, y B axis normal to the instrument 
radiator faces, and x B = y B x z B , as shown in Figure 6. 

The MAP attitude is sensed by an Inertial Reference 
Unit (IRU), two Autonomous Star Trackers (ASTs), a 
Digital Sun Sensor (DSS), and twelve Coarse Sun 
Sensors (CSSs); it is controlled by three Reaction 
Wheel Assemblies (RWAs), and a propulsion system. 

The IRU comprises two Kearfott Two-Axis Rate 
Assemblies (TARAs), one with input axes aligned with 
the z B and x B axes and the other with input axes aligned 
with the z B and y B axes. This gives redundant rate 
inputs on the z B axis; the DSS outputs can be 
differentiated to provide rates on the other axes in the 
event of an IRU failure. 

The boresights of the two Lockheed-Martin ASTs are in 
the ±y B directions. Each AST tracks up to 50 stars 
simultaneously in its 8.8° square FOV, matches them to 
stars in an internal star catalogue, and computes its 
attitude as a GCI-referenced quaternion with accuracy 
of 21 arc-seconds (lcr) around its boresight axis and 
2.3 arc-second s (lcr) in the other two axes. 



Figure 6: Spacecraft Layout 


The Adcole two-axis DSS has two heads, each with 64° 
square FOV and an accuracy of 1 arc-minute (3 ct). The 
centers of the FOVs of the two heads are in the x B -z B 
plane at angles of ±29.5° from the z B -axis. The CSSs 
are cosine eyes located in pairs looking outward from 
the edges of the six solar array panels, alternately 
pointing 36.9° up and 36.9° down from the x B -y B plane. 

The RWAs are Ithaco Type E wheels each with a 
momentum storage capacity of 70 Nms. The available 
reaction torque of each wheel is 0.35 Nm, but this is 
limited to 0.215 Nm by the MAP software to satisfy 
power constraints. The reaction wheel rotation axes are 
tilted 60° from the -z B axis and uniformly distributed 
120° apart in azimuth about this axis. The wheels serve 
the dual function of counterbalancing the body’s spin 
angular momentum to maintain the system momentum 
(i.e. body plus wheels) near zero while simultaneously 
applying control torques to provide the desired 
spacecraft attitude. The wheel axis orientations result in 
all wheel speeds being biased away from zero while the 
spin-scan observing motion is being executed, thus 
avoiding zero-speed crossings that would occur if the 
wheel spin axes were oriented along the spacecraft 
body frame co-ordinate axes. 

The propulsion system comprises eight monopropellant 
hydrazine Reaction Engine Modules (REMs) and 
associated hardware. Each REM generates a maximum 
thrust of 4.45 N. 

More detail on the MAP ACS hardware suite can be 
found in Ref. 14. 

MOMENTUM MANAGEMENT 

The choice of an L 2 orbit to minimize magnetic, 
thermal, and radiation disturbances precludes the use of 
magnetic sensing or torquing. Thus, the propulsion 
system provided for orbit maneuvers and stationkeeping 
is also used to unload accumulated system angular 
momentum after each orbit adjust. These occur several 
times in the phasing loops but no more than once every 
three months at L 2 to minimize interruptions of science 
observations. The RWAs can store on the order of 70 
Nms of angular momentum in non-spinning modes, and 
a significant fraction of this along the z B axis while 
spinning about this axis. While executing the Observing 
Mode spin-scan, however, the transverse momentum 
storage capacity (i.e. in the x B -y B plane) is limited to 3 
Nms, the amount that can be cycled among the three 
RWAs at the fast spin rate without adversely affecting 
attitude control. 
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Gravity-gradient, atmospheric drag, and outgassing 
torques are significant in the phasing loops; but the 
accumulated angular momentum of less than 1 Nms per 
orbit is easily stored until removal following orbit 
maneuvers at apogee or perigee. 

Solar radiation pressure torque is the only significant 
disturbance torque at L 2 , and the uniform rotation of the 
spin axis reduces its average along the x B and y B axes 
by more than two orders of magnitude compared to its 
instantaneous value. The only problematic component 
would arise from a “pinwheel” torque along the z B axis, 
which might result from an imperfect deployment of the 
solar array panels. The angular momentum is 
accumulated in inertial space, so it is clear from Figure 
5 that the pinwheel torque at one point in the orbit leads 
to a transverse angular momentum one-quarter orbit, or 
91 days, later. This means that any accumulation of 
angular momentum from the pinwheel torque of more 
than about 0.03 Nms per day would require momentum 
unloading more frequently than desired. 

Pre-flight estimates of the pinwheel torque gave angular 
momentum accumulation ranging from 0.0016 to 0.065 
Nms per day, depending on the accuracy of deployment 
of the solar arrays and the resulting symmetry of the 
spacecraft. 8 The worst-case estimate would reach the 
Observing Mode system angular momentum limit of 3 
Nms in 46 days, which is highly undesirable. Flight 
data indicates an angular momentum accumulation of 
about 0.006 Nms per day, which easily meets the three- 
month requirement. In fact, since this is less than 0.03 
Nms per day, Figure 5 shows that the pinwheel torque 
will begin to unload the accumulated angular 
momentum on the next quarter orbit, so no unloading 
by the REMs is required at all, in principle. The orbit 
perturbations at L 2 have also been well within 
requirements, so the current plan is to perform 
stationkeeping and momentum unloading only once 
every four months, rather than every three months. 

ACS OPERATIONAL MODES 

MAP has six ACS modes. The Observing, Inertial, 
Delta V, Delta H, and Sun Acquisition modes are 
implemented in the main spacecraft (Mongoose V) 
processor, while the Safehold Mode resides in the 
Attitude Control Electronics Remote Services Node 
(ACE RSN). Figure 7 shows the modes and the 
transitions among them. Anomalous behavior can result 
in autonomous transitions from any other mode to Sun 
Acquisition Mode or Safehold Mode, even though these 
transitions are not shown explicitly. The ACS modes 
are discussed below, including the sensors, actuators, 
and control algorithms used. 



Observing Mode 

Observing Mode is used for science operations to 
maintain the 22.5°±0.25° angle between the spin axis 
and Sun line and to implement the observing strategy 
shown in Figures 4 and 5. This is accomplished by 
specifying the Observing Mode attitude of the MAP 
spacecraft with respect to the RSR co-ordinate frame by 
the set of 3-1-3 Euler angles 10, 11 

/ 

<!>c= < t>0 + j < i > c dt > 
f 0 

=22.5° = 0.3927 rad, (lb) 

r 

Vc=Vo + l'i f c dt ’ (lc) 

'o 

where (fr c = — 1 rev /hour = —0.001745 rad /sec and 
\j/ c = 0.464 rpm = 0.04859 rad / sec are the desired 
spin-scan rates, and initial conditions determine 0 O and 
yr 0 . A commanded RSR-to-body quaternion and 

angular rate vector are computed from these Euler 
angles and rates by the standard equations. 10 11 An 
estimated RSR-to-body quaternion and angular rate 
vector are computed using IRU, AST, and DSS 
measurements in a Kalman Filter combined with a GCI- 
to-RSR quaternion computed onboard from ephemeris 
models. The desired control torque is computed by a 
proportional-derivative (PD) controller using RSR-to 
body quaternion and rate errors. 15, 16 A feedforward 
term including the commanded angular acceleration and 
a gyroscopic term is added to reduce hangoff. The 
commanded torque is distributed to the RWAs using a 
torque distribution matrix defined by the orientation of 
the RWAs in the body co-ordinate system. Normal exit 
from Observing Mode is by command only. 
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Inertial Mode 

As shown in Figure 7, Inertial Mode acts as a staging 
mode between the other operations of the spacecraft. 
This is an RWA- and IRU-based mode similar to 
Observing Mode, using the same Kalman Filter, but 
differs in that the commanded rates are zero and the 
feedforward terms are absent. Inertial Mode can either 
hold the spacecraft in an inertially fixed orientation or 
slew the spacecraft to a sequence of GCI-to-body 
quaternions from a Command Quaternion Table (CQT) 
uploaded from the ground. A slew is executed if the 
desired orientation is not close to the current spacecraft 
orientation. Normal exits from Inertial Mode are by 
command only. 

Delta V Mode 

Delta V Mode, which uses the REMs to adjust the orbit 
in either the initial phasing loops or for L 2 
stationkeeping, is only entered from Inertial Mode by a 
command sequence specifying burn duration, direction 
and start time. The desired attitude (in terms of a single 
quaternion or a CQT) and thrusters to be used can be 
configured either via command or by table load. The 
spacecraft remains in Inertial Mode to slew from the 
initial orientation to the desired attitude for the start of 
the delta V, and transitions to Delta V Mode at the start 
time of the requested burn. The only sensors used in 
Delta V Mode are the IRU and RWA tachometers. This 
mode uses a PD controller to hold the spacecraft to a 
commanded quaternion attitude while executing the 
Delta V burn. The output of the controller is 
transformed into thruster firing commands using a pulse 
width modulator with a minimum pulse width of 0.04 
sec. The desired attitude is held by off-pulsing the 
primary set of thrusters and on-pulsing the others. 
Normal exit is autonomously to Delta H Mode 

Delta H Mode 

Delta H Mode uses the REMs to unload spacecraft 
system angular momentum, which is computed using 
the RWA tachometers and IRU. It is used primarily 
upon exit from Delta V Mode; but can be commanded 
from Inertial or Sun Acquisition Mode if necessary, 
although this is not anticipated. The same pulse width 
modulator is used for Delta H as for Delta V, with the 
exception that all thrusters are operated in an on-pulsing 
manner for Delta H. If entry was from Delta V or 
Inertial Mode, the ACS autonomously transitions to 
Inertial Mode after the momentum has been reduced to 
less than 0.3 Nms. If Delta H Mode was entered from 
Sun Acquisition Mode, as discussed below, the 
autonomous exit upon completion of the momentum 
unloading is back to Sun Acquisition Mode. 


Sun Acquisition Mode 

Sun Acquisition Mode uses the CSS, IRU, and RWAs 
to acquire and maintain a thermally safe power-positive 
orientation, with the spacecraft z B axis within 25° of the 
Sun. Upon separation from the launch vehicle, MAP is 
in Sun Acquisition Mode, which must slew the 
spacecraft from any initial angle and any initial body 
momentum less than [13, 13, 55] Nms to a power- 
positive orientation within 40 minutes. If the body 
momentum exceeds the amount that can be handled by 
Sun Acquisition Mode, Delta H Mode is commanded to 
reduce the momentum to an acceptable level, after 
which the spacecraft returns to Sun Acquisition Mode. 
Transition to Inertial Mode can be commanded after the 
attitude has been initialized. Transition to the 
Mongoose control modes from the ACE Safehold Mode 
is through Sun Acquisition Mode. 

Safehold Mode 

Safehold Mode is implemented in the ACE, so it can be 
entered autonomously in the event of a Mongoose 
anomaly. It has two configurations, which differ by the 
rate information used. The first, Safehold/IRU, is a 
copy of the Sun Acquisition Mode in the Mongoose. 
The second, Safehold/CSS, is a minimum-hardware 
mode using only the RWAs and CSSs, with rate errors 
being computed by numerically differentiating the 
position error signals. Because it lacks body z rate 
information from the gyros, Safehold/CSS can tolerate 
less system momentum than can Sun Acquisition or 
Safehold/IRU Mode. Since the CSSs are insensitive to 
rotations about the Sun line, anti-runaway compensa- 
tion is applied to prevent the wheels from uncontrolled 
spinning about the satellite’s z-axis. This is 
accomplished by applying equal damping torques to the 
three wheels if the sum of their speeds exceeds a pre-set 
value, thereby suppressing z-axis rotation without 
applying a net torque in the x-y plane. Exit from either 
Safehold Mode is by ground command only. 

FLIGHT SOFTWARE 

By the preliminary design stage for the MIDEX 
program, tools existed that would make design, analysis 
and development an integrated process, allowing a 
reduction in manpower and a reduction in development 
time, consistent with the philosophy of the MIDEX 
program. There was also an interest in reusing software 
and developing reusable model/software libraries for 
quicker mission designs in the future. The MatrixX 
integrated analysis and design toolset from Integrated 
Systems, Inc. was selected because it possessed the 
desired capabilities. The MatrixX components used for 
MAP include a linear analysis tool (XMath), a 
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graphical environment for developing and executing 
nonlinear simulations (SystemBuild), an automatic code 
generation product (AutoCode), and a documentation 
generation product (Documentlt). 1 

Automatic Code Generation 

The decision to use automatically-generated code was 
an attempt to address some of the lessons learned from 
previous in-house spacecraft developments at Goddard, 
such as the Rossi X-Ray Timing Explorer (RXTE) and 
Tropical Rainfall Measuring Mission (TRMM). 
Following the RXTE and TRMM ACS developments, a 
need was seen to limit the manual interfaces required to 
design and develop an ACS subsystem. The previous 
design system was characterized by a large duplication 
of effort, with three separate teams— the analysts, the 
flight software developers, and the developers of the 
hybrid dynamic simulator (HDS) used to test the flight 
software — designing the same system independently. 

An overview of the previous design process, depicted in 
Figure 8, shows that the analysis, simulation, code, and 
test efforts were developed independently, rather than 
branching from a single design point. This process 
relied on written documentation to describe changes in 
the design that needed to be reflected in all three 
systems. One person was dedicated to the development 
of the high fidelity simulation (HiFi), which was not 
useful in the linear analysis of the system, and another 
person was a dedicated documentation engineer, needed 
to keep the flight software and test simulation teams 
informed of changes. This process was prone to manual 
implementation errors and misunderstandings, which 
resulted in the FSW team not always initially 
implementing the algorithms as the design team had 
envisioned them. Additionally, the Hybrid Dynamic 
Simulator (HDS), designed to test the flight software, 
was designed by a separate team and was unable to 
benefit from any efficiencies of co-development. 

The MatrixX software was used to create a single 
design point in the HiFi simulation that every team 
member could use, rather than needing one HiFi and 
several low fidelity simulations. The same HiFi could 
be used for the linear stability analysis and, using other 
add-ons in the MatrixX toolkit, could be the basis of 
automatic code and documentation generation. This 
eliminated a significant manual documentation and 
translation effort and had the significant additional 
benefit of ensuring that all members of the ACS design 
team were working from the same single design point. 
It also reduced the risk of errors associated with manual 
translation. The process used for the MAP software 
development is shown in Figure 9. 



Figure 8: Previous Development Process 



Figure 9: Integrated Development Process 

The MAP software development was based on HiFi, as 
shown in Figure 9, but the HDS software was not 
AutoCoded. This minimized the risk of an error going 
undetected by being replicated in both places. 
AutoCode was used for the control law algorithms and 
system momentum calculations in the Mongoose V 
flight software only, and not in the ACE software. This 
limited risk by not automatically generating code for 
any flight software component that required a direct 
interface to ground commands or to the spacecraft 
sensors and actuators. Further, because the control laws 
had a high algorithm-to-code ratio and a clearly defined 
interface to the rest of the system, they provided a good 
test of the code-generation method. A final benefit to 
using AutoCode primarily on the spacecraft control 
laws is that these are good candidates for reuse on 
future missions. 
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Automation of Software Testing 

RXTE and TRMM flight software test procedures were 
developed on the ground system. The initial conditions 
for these tests were then given to an ACS analyst to 
replicate the initial conditions in HiFi, which were used 
to define the expected test results. The flight software 
test procedures were executed in the flight software lab. 
The results were plotted using the test author’s favorite 
plotting package, which was usually different from any 
of the other tester’s favorite plotting package. The 
resulting plots from the HiFi and the flight software test 
execution were then held side to side and visually 
compared. The plethora of variables that needed to be 
consistent between the HiFi, HDS, and flight software 
were maintained in a spreadsheet and manually entered 
into the HiFi, HDS, and flight software. Figure 10 
shows this process. As denoted by the gray shaded 
arrows, there were many manual steps in this process 
that were prone to errors. 



Figure 10: Manual Flight Software Test Process 


The RXTE/TRMM process encountered pitfalls in each 
of these manual steps, namely replicating the initial 
conditions, plotting of the results, and maintaining 
consistency between all of the variables. Especially in 
the infancy of these flight software test programs, it was 
not unusual to go through several iterations of a 
particular test, trying to match the initial conditions and 
variables. Inconsistencies would be discovered in the 
plot results review; for example, that the Kalman Filter 
was not enabled in the flight software test but was 
enabled in the HiFi version of the test, creating different 
results. Sometimes the inconsistencies were more 
subtle, such as a number swap of one of the digits of a 
variable. Time-consuming iterations were also made in 
the plotting process, since consistency in scaling and 
units between the flight software and HiFi plots is 
extremely important. Many times, the flight software 
plots would have to be recreated in order to scale the 


plots with enough detail to verify the results with HiFi 
or to change the units to facilitate comparison. 

Finally, the separate nature of the flight software testing 
and HiFi paths slowed the verification process. The 
HiFi runs could only be created by a member of the 
ACS analysis team familiar with the HiFi, and could 
only be executed with any confidence after the flight 
software test results were reviewed. The limited number 
of analysts, as well as the fact that the analyst would 
need multiple interactions with the tester for each test, 
frequently created test verification bottlenecks. 

On MAP, many of the manual processes were 
automated, streamlining the testing process. 20 Figure 1 1 
illustrates the flight software test flow that MAP 
followed, highlighting the areas that were automated. In 
contrast with RXTE/TRMM, MAP had tools for 
dissecting a flight software test procedure and 
automatically producing a HiFi script that replicated the 
flight software test procedure flow. In addition, MAP 
had a centralized database that defined and linked all of 
the variables used in HiFi, HDS, and the flight 
software. With the press of a button, the database 
generated the source files for each of these systems that 
guaranteed consistency. Finally, the plotting process 
was streamlined since the MAP tools defined a standard 
set of plots that were used to present the flight software, 
HiFi, and HDS test results on one plot. 
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Figure 11: Automated Flight Software Test Process 


One of the keys to the success of the MAP flight 
software testing effort was the parameter database used 
for configuration management of virtually all the 
variables, control gains, failure detection and correction 
(FDC) parameters, and other parameters used by the 
MAP ACS. As shown in Figure 11, the database fed 
into all of the ACS elements. As each parameter was 
placed in the MAP database, it was assigned to an 
appropriate subsystem engineer to populate the 
database with the correct information and verify it. 
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Upon release each new version of flight software for 
either the spacecraft main processor or attitude control 
electronics, a corresponding release from the MAP 
database was created. Output templates from the 
database were created as header files for the flight 
software; additionally, script files for initializing the 
HDS and HiFi were generated at the same time. In this 
way, a consistent set of parameters across each test 
system component was assured for flight software tests 
and HiFi verification simulations. 

The MatrixX integrated toolkit, its Xmath command 
environment, and its SystemBuild simulation 
component lend themselves especially well to this 
automation process. The MathScript scripting language, 
based on Xmath, acts as the glue that holds the 
simulation and testing process together. It was used 
extensively with the MAP HiFi to set up simulations 
and to perform many data analysis functions. 
MathScript allows flight software and HiFi simulation 
to be analyzed, interfaces with MatrixX’s SystemBuild 
simulation environment to allow simulations to be 
created and run, and provides the mechanism for 
creating comparison plots between flight software and 
HiFi simulation verification data. 

MathScript is a complete scripting language for data 
processing, particularly matrix processing, and provides 
all of the functions necessary for interfacing numerical 
data and the HiFi simulation, but it lacks extensive 
string processing capability. However, MathScripfs 
ability to interface with the native operating system 
makes it possible to add the string processing functions 
needed to process Systems Test and Operations 
Language (STOL) procedures, Record Definition 
Language statements (RDLs), and the sequentially 
printed data output files from the MAP ground system, 
which are mixed numeric and text. Test data can be 
read in and processed using string processing 
extensions programmed in Perl. Using SystemBuild 
Access, an extension to Xmath that allows it to access 
and control SystemBuild simulations, MathScript 
functions can create and run HiFi simulations to 
perform data analysis and test verification. 

It should be noted that while the MatrixX integrated 
toolkit lends itself particularly well to the design of 
automated test tools, such toots could be designed in 
other settings. The key ingredient is a scripting 
language around which the rest of the system can be 
built. The Matlab/Simulink environment, using 
Matlab’s m-file scripting, could also be used. Even a 
dedicated simulation such as one written in a language 
such as FORTRAN or C can be used with these 
automated test techniques. 


FLIGHT EXPERIENCE 

The Delta launch vehicle placed the MAP spacecraft on 
a very accurate trajectory with body angular momentum 
of only 6.2 Nms at separation, well within the 
capability of the Sun Acquisition Mode, which acquired 
the Sun within 15 minutes. Maximum pointing errors 
during the nine Delta V maneuvers performed in the 
first three months of the mission were smaller than 
predicted (3.7° vs. 5.5°), and imparted velocity 
increments were accurate to 1%. Less than 15 kg of 
hydrazine propulsion fuel was expended to get to L 2 , 
about half the amount budgeted for this phase of the 
mission. The 57 kg of fuel remaining for stationkeeping 
and momentum unloading at L 2 will easily support a 
four-year extended mission. 

Stray light in the ASTs caused some problems during 
the phasing loops. Both ASTs lost track when the Moon 
was within a degree or so of the FOV, but only for a 
few seconds in a spin cycle, and only for three spin 
cycles in any precession cycle. No more than 13 AST 
readings were lost in a precession cycle. There is no 
Moon, Earth, or Sun interference at L 2 , and the ASTs 
have been routinely tracking 15 to 40 stars in the 
absence of interference. Attitude knowledge has been 
better than 20 arc seconds per axis, easily meeting the 
three-axis root-sum-square requirement of 78 arc 
seconds. The Sun angle has been maintained between 
22.44° and 22.54° in Observing Mode, as illustrated by 
the perfect circle traced by the Sun vector over several 
hours in Figure 12. 


OSS Sun Vector X v* Y 



Figure 12: DSS Measurements in Observing Mode 
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Initially, the precession rate <j> in Observing Mode did 
not meet its 5% accuracy requirement, showing a 7% 
variation at the spin period. This was attributed to an 
inaccurate value of system momentum in the 
gyroscopic feedforward loop arising from a scale factor 
error in the RWA tachometer signals. Evidence for this 
was that the magnitude of the system momentum, 
which should be constant, had a 0.4 Nms oscillation at 
spin period and increased during spin-up by 1.0 Nms. 
Comparing a high-fidelity simulation with flight data 
determined that the oscillation and spin-up offset could 
be removed by a small change in the tachometer scale 
factors by about 2.5% for RWA1 and about 4% for 
RWA2 and RWA3. After loading these new scale 
factors, the variation of the precession rate was 
dramatically reduced, as were the spin-period 
oscillation and the spin-up offset in the computed 
system momentum magnitude shown in Figure 13. 

Charged particle flux from extreme solar activity on 
November 5, 2001 caused a power-on reset of the 
Mongoose processor. The ACS transitioned 
autonomously to Safehold Mode in the ACE, which 
functioned exactly as designed to keep MAP safe. The 
transition to Safehold Mode was discovered by 
operations staff at the next telemetry pass about 12 
hours later, and recovery to Observing Mode was 
accomplished within three hours of this discovery. 


CONCLUSIONS 

The Microwave Anisotropy Probe attitude control 
system was designed and developed more efficiently 
than those of previous missions. Flight software 
development was facilitated by use of integrated 
analysis and design tools to increase the flight software 
team’s communication and integrate their work more 
tightly. Team members abandoned the specialization 
found on previous programs; analysts; flight software 
developers, systems engineers and testers shared a 
common design point. Standardizing interfaces and test 
procedures and developing new data analysis tools 
removed many of the testing bottlenecks encountered in 
previous programs, so that a number of rounds of 
regression testing to accommodate late software 
changes and additions could be performed in a very 
timely, efficient, and thorough manner. 

The attitude control system described in this paper and 
developed using these tools has successfully met the 
demanding requirements of the Microwave Anisotropy 
Probe mission. These include the need to function 
robustly far from the Earth where no magnetic field is 
useful for sensing or actuation, and with infrequent 
telemetry passes. The processor upset on November 5, 
2001 illustrated the importance of having a safemode 
control capability that is independent of the primary 
control hardware and software. 



Figure 13: Pre- and Post-Calibration System Angular Momentum Magnitude 
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